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FOREWORD 


At their March 1988 meeting, members of the National Aeronautics 
and Space Administration (NASA) Information Resources Management 
(IRM) Council expressed concern that NASA may not have the 
infrastructure necessary to support the use of Ada for major NASA software 
projects. Members also observed that the agency has no coordinated 
strategy for applying its experiences with Ada to subsequent projects 
(Hinners, 27 June 1988). 

To deal with these problems, the IRM Council chair appointed an 
intercenter Ada and Software Management Assessment Working Group 
(ASMAWG). They prepared a report (McGarry et al., March 1989) entitled 
Ada and Software Management in NASA: Findings and Recommendations. That 
report presented a series of recommendations intended to enable NASA to 
develop better software at lower cost through the use of Ada and other 
state-of-the-art software engineering technologies. The purpose of the 
present document is to describe the steps (called objectives ) by which this 
goal may be achieved, to identify the NASA officials or organizations 
responsible for carrying out the steps, and to define a schedule for doing so. 

This document sets forth four goals: 

• Adopt agency-wide software standards and policies 

• Use Ada as the programming language for all mission software 

• Establish an infrastructure to support software engineering, 
including the use of Ada, and to leverage the agency’s software 
experience 

• Build the agency’s knowledge base in Ada and software 
engineering 

Each of the four main sections of this document deals with one of the 
goals and the objectives that fall under it. Appendix A presents a schedule 
for achieving the objectives and goals. 

Since the abolishment of the Office of the Chief Engineer, it appears 
that NASA has lacked an organization chartered to oversee the agency’s 
software engineering and agency-level software standards, policies, and 
guidelines. During the development of this plan, the ASMAWG concluded 
that the apparent lack of such an organization is a serious shortcoming of 
the infrastructure supporting software management in the agency. If such an 
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office were (re)established, or if a charter for such duties were added to 
that of an existing office, this plan could be more effectively implemented 
and sustained. 

Certain of the objectives set forth in this plan would more suitably be 
assigned to such a headquarters office: specifically, Objectives 1.1, 1.2, 

2.1, 3.1, 3.2, and 4.3. In the absence of such an office, the plan assigns 
responsibility for the attainment of each objective to an existing 
organization. For example, the Software Engineering and Ada 
Implementation Task Force (SEA1TF), which is responsible for 
implementing this 5-year plan and advising the centers about Ada and 
software engineering (Objective 3.1), has been assigned to the IRM Council; 
but it would more appropriately be assigned to a headquarters engineering 
office. 



IV 


Table of Contents 


Goal 1: Develop Policies and Standards 1 

Objective 1.1: NASA Management Instruction Mandating Ada .... 1 

Objective 1.2: Standards 2 

Objective 1.3: Risk Management 3 

Objective 1.4: Software Development Environments 4 

Objective 1.5: Contractor Incentives 5 

Goal 2: Use Ada for All Mission Software 7 

Objective 2.1: Three-Phase Transition 7 

Goal 3: Establish Support Organizations 11 

Objective 3.1: Software Engineering and Ada Implementation 

Task Force ■ 11 

Objective 3.2: Software Process Engineering Task Force 12 

Goal 4: Develop Knowledge Base 15 

Objective 4.1: Coordination of Research and Development 15 

Objective 4.2: Training 16 

Objective 4.3: Software Measurement Program 17 

Appendix A — Schedule 19 

Appendix B — Persons Consulted 33 

References 35 

Glossary of Acronyms 37 




Goal 1: Develop Policies and Standards 


Develop and adopt a set of agency-wide software policies 
and standards to support the use of Ada and state-of-the-art 
software engineering. 

Objective 1.1: NASA Management Instruction Mandating 
Ada 

Issue a NASA Management Instruction (NMI) that states 
that Ada is to become the standard programming language 
for NASA mission software. 

Plan 


Our definition of mission software is as follows: 

Mission software is all software that is critical to the design, 
planning, operation, control, or testing of any NASA flight 
project. It comprises all flight software and all ground soft- 
ware that directly interface with the flight systems or could 
affect mission planning, control, or operations. Mission soft- 
ware includes, for example, all software used in flight plan- 
ning, flight dynamics, mission control, and flight readiness. It 
also includes all software used to simulate, model, or test any 
of the foregoing software functions. 

The NMI should contain an official definition of mission software simi- 
lar or identical to that above, list categories of software to which the NMI 
does not apply, and specify a process for obtaining a waiver. It should also 
state that NASA will evolve to the use of Ada for all mission software 
through a three-phase process (Objective 2.1). 

Responsibility 

Code NT (specifically, the Information Resources Management (IRM) 
Council). 
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Goal 1: Develop Policies and Standards 


Objective 1.2: Standards 

Develop and adopt tailorable standards for software devel- 
opment, management, acquisition, and assurance. 

Plan 

These standards should apply to all NASA software. They should be 
developed with a view to general software engineering principles and 
NASA’s specific needs. They should not specify the details of the develop- 
ment process but should concentrate on the products to be developed and 
the reviews at which compliance of these products with the required stand- 
ards is to be demonstrated and assessed. The standards may, however, 
specify high-level requirements for such processes as configuration manage- 
ment, quality assurance, and the collection and reporting of metrics. The 
management standard should include a requirement for developing and im- 
plementing a risk management plan for all critical software projects (Objec- 
tive 1.3). 

The standards should be able to be tailored by adapting specific sec- 
tions to fit the needs of a specific project. Either the NASA project manager 
or the contractor may initiate proposals for tailoring. The NASA project 
manager should have the authority to approve tailoring. 

Representatives from private industry should review draft standards 
before their final approval. In addition, standards should be subject to peri- 
odic revision in light of changing software technology. 

Responsibility 

Code QR. 
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Goal 1: Develop Policies and Standards 


Objective 1.3: Risk Management 

For any “critical” software project, require managers to de- 
velop and implement a risk management plan. 


Plan 


NASA should develop and adopt a policy requiring risk management 
plans for critical software projects. The purpose of such a plan is to assess 
software development risks and then control them through risk management 
planning, risk monitoring, and risk resolution. 

The new agency-level standard for software management (Objec- 
tive 1.2) should contain a requirement to develop and implement risk man- 
agement plans. It should also define the criteria for classifying projects as 
“critical” and describe the format and content of these plans. It should state 
that risk management plans are to be approved and monitored at the center 
level. A handbook containing guidance for developing and implementing 
risk management plans should be available to project managers. Each cen- 
ter should develop an approach for approving and monitoring risk manage- 
ment plans. 

Responsibility 

Code QR. 
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Goal 1: Develop Policies and Standards 


Objective 1.4: Software Development Environments 

Evolve toward a common software support environment. 

Plan 


NASA should develop a set of functional requirements for a NASA 
software support environment. The requirements analysis should be based 
on a review of the requirements for the Space Station Freedom Program 
Software Support Environment (SSE) and other environments and on expe- 
riences gained from designing and using these environments. NASA should 
eventually impose the functional requirements on all in-house and contrac- 
tor software support environments for mission software. In addition, NASA 
should develop an environment that meets the functional requirements. 

The common environment should be developed using the following ap- 
proach: 

1. The Software Engineering and Ada Implementation Task Force 
(SEAJTF) (see Objective 3.1) should define the functionality re- 
quired for a NASA-wide software support environment. 

2. The SEA1TF should produce a high-level report describing “Con- 
cepts, Capabilities, and Architecture of the NASA Software Sup- 
port Environment.” 

3. Code RC should support research into concepts of the software 
support environment. 

4. Code RC should support the design and implementation of a pro- 
totype environment. 

5. Codes E, M, S, and T should ensure that one or more centers 
build or use full operational environments based on the concepts 
developed by Code RC. 

Responsibility 

Code RC. 
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Goal 1: Develop Policies and Standards 


Objective 1.5: Contractor Incentives 

Establish an Ada incentive program for NASA software con- 
tractors. 


Plan 


NASA should first determine what the largest barriers are to contrac- 
tors’ adoption of Ada and state-of-the-art software engineering. These would 
probably include such factors as the costs of training or hiring Ada software 
engineers; the costs of acquiring or developing an Ada software support 
environment; the inherent risks of living near the cutting edge of technol- 
ogy; and organizational inertia. In particular, NASA should determine the 
principal barriers to software reuse. 

NASA should then develop a plan for overcoming these barriers 
through changes in the acquisition process. The plan should include consid- 
ering a contractor’s Ada and software engineering experience in evaluating 
proposals; sharing the costs of training and other transition activities; shar- 
ing the costs of acquiring or developing tools; schedules and award fees that 
promote readiness to use Ada at specified stages of a contract; and mecha- 
nisms by which a contract can encourage reuse. 

Responsibility 

Code H. 
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Goal 2: Use Ada for All Mission Software 


Use Ada as the programming language for all mission soft- 
ware. 

Objective 2.1: Three-Phase Transition 

Carry out a phased transition at each center. 


Plan 


NASA should evolve to Ada through a three-phase process extending 
from 1989 through 1998. This phased approach will permit Ada technology 
and the agency’s Ada capabilities to mature before NASA begins using the 
language as a matter of general policy on large, critical projects. It also will 
allow NASA to reconsider the policy periodically on the basis of experience 
gained. The phases should begin no later than the beginning of the follow- 


ing fiscal years (FY): 

FY 1990 

Pilot projects 

FY 1992 

Selected production software 

FY 1995 

Expanding categories of mission software 
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Goal 2: Use Ada for All Mission Software 


By the beginning of FY 1998, all new mission software should be under 
development in Ada. 

In Phase 1, NASA and contractor personnel should acquire the training 
and experience needed to use Ada on production projects. During this pe- 
riod, NASA personnel should participate in the Ada and software engineer- 
ing training programs specified in their center’s transition plan. They should 
also participate in pilot projects involving relatively unsophisticated and 
noncritical systems or parts of systems, for example, tools, benchmarks, 
prototypes, simulators, and test drivers. NASA personnel should manage 
these projects and also participate in some or all of the design and imple- 
mentation. Participants in such projects should record lessons learned that 
may be applicable to future projects. Such projects will provide a basis for 
developing standards and guidelines concerning Ada management and de- 
velopment techniques. These projects will also absorb the 10- to 30-percent 
overhead that is expected in initial Ada projects because of learning curves 
and other transition costs (Reifer, December 1987). 

In Phase 2, NASA should gain experience in using Ada on large, pro- 
duction projects. Projects should establish methods of measurement to 
capture the results of using Ada and other software engineering technolo- 
gies (Objective 4.3). Projects, centers, and the agency should refine soft- 
ware standards and guidelines in light of experiences on these initial 
production projects. Phase 2 projects will also provide feedback on the most 
effective techniques for managing software risks. 

In Phase 3, each center should gradually widen the scope of Ada use 
until it encompasses all new mission software by FY 1998. In Phases 2 and 
3, a center should widen the scope of Ada use within a given category of 
software in order to maximize opportunities for reuse. 

The first step in attaining this objective is the development of a three- 
phase Ada transition plan for NASA as a whole. Each center should then 
develop a more detailed plan that is compatible with the agency plan, 
though it need not have exactly three phases. Each of the center’s transition 
plans should address all the points described by “A Model for Transition to 
Ada” in Section 4 of McGarry et al. (March 1989). The plan should explain 
how the center will adapt the agency-level core training curriculum (Objec- 
tive 4.1) to meet the needs of the center’s personnel in software engineering 
and Ada. The centers’ transition plans should be submitted to the SEATTF 
and updated every 2 years during the Ada transition period. 

Both the agency-level and center-level plans should define criteria for 
determining when each phase should begin. These criteria should at least 
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Goal 2: Use Ada for All Mission Software 


require that the current phase has demonstrated that the center and its 
contractors have adequate training, Ada environments, and ability to man- 
age Ada risks for the projects envisioned for the next phase. 

Responsibility 

Code NT. The center directors should be responsible for developing 
compatible Ada transition plans for their centers and demonstrating suc- 
cessful completion of each phase. 


Goal 3: Establish Support Organizations 


Establish an infrastructure to support software engineering, 
including the use of Ada, and to leverage the agency’s soft- 
ware experience. 

Objective 3.1: Software Engineering and Ada Implementa- 
tion Task Force 

Establish a Software Engineering and Ada Implementation 
Task Force. 


Plan 


An intercenter task force, the SEATTF, should be established. It should 
be responsible for implementing this 5-year plan and advising the centers 
about Ada and software engineering. 

Preferably, the SEAITF should be organized by a permanent headquar- 
ters organization that is responsible for setting agency-wide software engi- 
neering standards, policies, and guidelines (see Foreword). However, since 
no such permanent organization yet exists, we are recommending that the 
task force report to Code NT in the interim. 

The SEAITF should consist of about 10 senior software engineers rep- 
resenting a broad spectrum of agency centers and functions. The chair of 
the SEAITF should be appointed by the chair of the IRM Council and 
should make quarterly reports to the IRM Council. 

The chair of the IRM Council should appoint the other members of the 
SEAITF from candidates submitted by the center directors. Members should 
serve terms of 2 to 4 years and should devote 50 to 100 percent of their 
time to the SEAITF, which should meet about once per month. 

The SEAITF should operate for at least the first 5 years of NASA’s 
transition to Ada. After 5 years, the chair of the IRM Council should deter- 
mine whether the SEAITF should be dissolved or should be extended for 
2-year intervals, possibly at a reduced level of support. 

Responsibility 

Code NT (specifically, the IRM Council). 
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Goal 3: Establish Support Organizations 


Objective 3.2: Software Process Engineering Task Force 

Establish a Software Process Engineering Task Force 
(SPETF) to support the evaluation and improvement of the 
agency’s software acquisition and in-house development 
processes. 


Plan 

Members of the SPETF should be trained in the Software Engineering 
Institute’s method for assessing software engineering capabilities 
(Humphrey et al., September 1987). They should then adopt this method, or 
some similar one, for the internal assessment of NASA’s software engineer- 
ing and management capabilities. The SPETF should also develop an analo- 
gous method for evaluating NASA’s software acquisition processes. 

The duties of the SPETF should include the following activities: 

• Developing criteria, questions, and analytical techniques for evalu- 
ating the agency’s software acquisition and in-house development 
processes 

• Conducting assessments of organizations at various NASA centers 

• On the basis of the assessments, formulating recommendations 
about how the organizations can improve their current processes 

• Training personnel at the centers to conduct their own assess- 
ments 

The SPETF’ s assessments and resulting recommendations will not be 
audits or personnel evaluations but mechanisms to stimulate continual 
growth of NASA’s software engineering capabilities. 

The SPETF should consist of 10 to 15 senior software engineers repre- 
senting a broad spectrum of agency centers and functions. The SPETF chair 
should be appointed by the chair of the IRM Council and should make 
quarterly reports to the IRM Council. The chair of the IRM Council should 
appoint the other members of the SPETF from candidates submitted by the 
center directors. They should serve terms of 2 to 4 years. 

It would be preferable for the SPETF, like the SEAITF, to be attached 
to a permanent headquarters organization responsible for the agency’s soft- 
ware engineering. Since no such headquarters organization currently exists, 
in the interim the SPETF should be an intercenter task force that reports to 
the IRM Council. 
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Goal 3: Establish Support Organizations 


Once the SPETF has developed the assessment criteria, questions, and 
procedures, each member should contribute about 40 percent of his or her 
time to the work of the SPETF. In addition to visiting centers to conduct 
assessments, the SPETF should meet quarterly to coordinate its activities. 
After performing a few assessments itself, the SPETF should spawn other 
groups to perform other assessments. 

The IRM Council should evaluate the effectiveness of tne SPETF every 
2 years and take any necessary corrective actions. 


Responsibility 

Code NT (specifically, the IRM Council). The other program offices 
(especially Codes E, M, S, and T) should take an active role. 


13 







Goal 4: Develop Knowledge Base 


Build the agency’s knowledge base in Ada and software engi- 
neering. 

Objective 4.1: Coordination of Research and Development 

At the agency level, plan and coordinate software research 
and development, more of which should pertain to Ada. 


Plan 


The software engineering research at the centers should be coordinated 
by a single agency-level research office so that it becomes part of an inte- 
grated research program. 

In addition, the agency’s research efforts that pertain to Ada should be 
expanded. The main thrust of this research for the next 5 years should be 
experimentation, measurement, and evaluation of Ada-related technologies. 
NASA Ada research should not duplicate private-sector efforts such as the 
development of compilers. Rather, it should address the implications of Ada 
and related software engineering technology for NASA applications. It 
should include such topics as standards and methods, portability, reuse, and 
Ada’s effect on management practices. 

Code RC should identify Ada as a major area of its research program, 
the NASA Initiative in Software Engineering (NISE). Code RC should also 
review all completed Ada research in NASA and produce a report on the 
results and implications of these studies so that the lessons learned from 
them are not lost. Code QR should consider this information in developing 
software standards and guidelines (Objective 1.2). 

Responsibility 

Code RC. Program offices such as Codes E, M, T, and S should work 
with Code RC in infusing resulting technology into NASA missions. 
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Goal 4: Develop Knowledge Base 


Objective 4.2: Training 

Develop and implement an agency-wide core curriculum in 
software engineering and Ada. Each center should adapt the 
core curriculum to its specific requirements. 

Plan 

NASA should create an agency-wide core curriculum that addresses 
such topics as software management, life cycles, quality assurance, configu- 
ration management, and computer-aided software engineering. It should in- 
clude sequences of courses recommended for different categories of 
personnel, that is, well-defined tracks for such categories as managers, de- 
velopers, and quality engineers. 

Code ND should begin by defining the agency’s needs for training in 
the areas of software development, management, acquisition, and assur- 
ance. It should also assess existing NASA curricula. It should then define a 
new NASA curriculum in Ada and software engineering and should define 
tracks for NASA personnel. This curriculum should be coordinated with 
contractors’ curricula in these areas. 

The centers should adapt the agency-level curriculum to their needs 
and implement it. Managers should ensure that their personnel take se- 
quences of courses suited to their backgrounds artd responsibilities and that 
they have opportunities to apply the course material to projects. The cen- 
ters’ courses should be available to headquarters personnel. 

Responsibility 

Code ND. In each center’s Ada transition plan, the center’s education 
office should adapt the core curriculum to that center’s needs. 


16 


Goal 4: Develop Knowledge Base 


Objective 4.3: Software Measurement Program 

Establish an agency-wide program to collect and use soft- 
ware metrics. 


Plan 

NASA should have a standard set of software metrics and a policy that 
requires all mission software development projects to collect and store 
them. These metrics should be studied a nd us ed in continuing efforts to 
improve NASA’s software development processes by identifying their 
strengths and weaknesses. 

Code NT should begin by defining the software measurement program, 
using experiences gained by the Goddard Space Flight Center Software En- 
gineering Laboratory (SEL). Code NT should then develop a handbook de- 
fining metrics and methods of collecting and storing them. Initially, the 
metrics program should focus on the effectiveness of Ada and related soft- 
ware engineering methods and tools. The metrics should be simple. For 
example, they might only measure effort and error frequencies. Following 
the publication of the handbook, the centers should establish procedures for 
collecting, storing, and interpreting these metrics. 

Because of its experience in sponsoring SEL research, Code T should 
play an active role in the measurement program. Code RC should partici- 
pate because of the measurement program’s relevance to NASA’s software 
research. 

Responsibility 

Code NT. 
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GOAL 1 : Develop and adopt a set of agency-wide software policies and standards to support 
the use of Ada and state-of-the-art software engineering. 
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Issue policies requiring 
use of the standards 
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GOAL 1: Develop and adopt a set of agency-wide software policies and standards to 
support the use of Ada and state-of-the-art software engineering. 
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GOAL 2: Use Ada as the programming language for all mission software. 
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GOAL 3: Establish an infrastructure to support software engineering, including the use of Ada, 
and to leverage the agency's software experience. 
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Decide to terminate or 
extend SEAITF 



















GOAL 3: Establish an infrastructure to support software engineering, including the use of Ada, 
and to leverage the agency's software exnerience. 
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Complete first internal 
assessment 
















GOAL 4: Build the agency's knowledge base in Ada and software engineering. 
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Report on impact of software 
technology 
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Glossary of Acronyms 


ASMAWG 

FY 

IRM 

NASA 

NISE 

NMI 

SEAITF 

SEL 

SPETF 

SSE 


Ada and Software Management Assessment Working Group 
fiscal year 

Information Resources Management 
National Aeronautics and Space Administration 
NASA Initiative in Software Engineering 
NASA Management Instruction 

Software Engineering and Ada Implementation Task Force 
Software Engineering Laboratory 
Software Process Engineering Task Force 
Software Support Environment 
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